Subject: DLSW MIB

From: Brian Jewell <[email-masked]>
Date: Fri, 2 Jun 1995 09:47:27 -0700 (PDT)

Everyone,

Re: DLSW MIB...some comments and corrections:

To illustrate some concerns about the dlswTConnOperTable, I enclose an excerpt
from RFC 1212:

   "In defining a conceptual row, it is useful to consider the
    optimization of network management operations which will act upon its
    columnar objects.  In particular, it is wisest to avoid defining more
    columnar objects within a conceptual row, than can fit in a single
    PDU.  As a rule of thumb, a conceptual row should contain no more
    than approximately 20 objects.  Similarly, or as a way to abide by
    the "20 object guideline", columnar objects should be grouped into
    tables according to the expected grouping of network management
    operations upon them.  As such, the content of conceptual rows should
    reflect typical access scenarios, e.g., they should be organized
    along functional lines such as one row for statistics and another row
    for parameters, or along usage lines such as commonly-needed objects
    versus rarely-needed objects."

Is it possible that the size of a row in the dlswTConnOperTabletable might 
be considered excessive?? 

Also, has consideration been given as to the "overhead" of keeping all these 
counters (particularly "InDataOctets" and "OutDataOctets")? Overhead can 
be an important issue to router vendors.

I suppose that the argument can be made that, from the standpoint of 
evaluating performance, this information is useful. But how much meaning 
will it have to a typical network administrator sitting at an NMS console? 

That's not to say that many of these objects shouldn't be included in the 
MIB...  But could the spirit of SNMP be better served if some of these 
objects were placed in a separate table (or preferably a separate group - 
as it is considered unacceptable to implement a "portion" of a group)? I would
like to know if there are other opinions on this.

Also, by way of more mundane (and less controversial) comments, I have
found the following errors in the MIB:

1) A typo for the OID for the "dlswTConnOperPartnerSapList" (it is defined
as a leaf of "dlswTConnOperResourceSnaEntry" in my copy of the MIB).

2) Another typo: "dlswTConnOperEntry ::= SEQUENCE { ... " should begin with 
an uppercase 'D' (e.g. "DlswTConnOper..."). (This seems like a minor typo but 
it really caused my MIB compiler to go non-linear).

3) "dlswTConnOperPartnerNBExcl" is specified as two conflicting types (INTEGER
and TruthValue). The same error exists for the "dlswTConnOperPartnerMacExcl" object.

Thanks.

Brian Jewell
3Com, Inc.